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FOREWORD 


This standard provides the principles and details for declarations necessary between members of a supply chain relationship. 
This standard is the first in a series of standards that permits segmentation of declaration details based on the subject and 
scope of the declaration as well as the manufacturing domain. This standard contains general information and is supple- 
mented by Sectional standards requiring more detailed information such as material declarations, quality profiles, or codes 
of conduct. 


As an example, Directive 2002/95/EC of the European Parliament and of the Council of 27 January 2003 on the restriction 
of the use of certain hazardous substances in electrical and electronic equipment requires information on a list of banned 
substances. These substances can be reported within one of the Sectional standards of the 175x series. In particular, the Sec- 
tional standard (IPC-1752) establishes information exchange requirements regarding the substances and materials that com- 
prise the bulk material, component, Printed Circuit Board (PCB), sub-assembly, etc. 


Since the 175x standards are designed to be implemented in software tools, the standard is comprised of two types of speci- 
fications: (1) defining the minimal functional requirements for compliant software, and (2) defining the data format and 
structure for exchange. The data format is based on an Extensible Markup Language (XML) schema, which in turn is rep- 
resented by a Unified Modeling Language (UML) model. All 175x compliant software shall conform to the appropriate 
UML model. Any 175x data exchange shall conform to the XML schema requirements as herein specified in order to com- 
ply with this standard. Such XML data can be extracted by the requester to automate the data transfer into his internal sys- 
tems, thereby insuring accurate, efficient, and reliable communication. 


This standard is designed to serve the public interest by facilitating the transfer of information along the supply chain 
through a common data model and XML schema. Existence of such standards and publications shall not in any respect pre- 
clude any member or nonmember of IPC from manufacturing or selling products not conforming to such standards and pub- 
lications, nor shall the existence of such standards and publications preclude their voluntary use by those other than IPC 
members, whether the standard is to be used domestically or internationally. 


In addition to the TAEC 'Position Statement on Specification Revision Change' (located on the inside front cover of this docu- 
ment) which states that the use of the new revision is recommended but not automatically required for an existing relationship; 
in the case of materials declarations, use of the new version of the standard is recommended by the committee because it sup- 
ports current regulations. 


In this revision of the 175x series, only the data format and functional requirements are specified. Development of human 
readable data entry and viewing tools are intentionally left in the domain of third party software providers. 
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Generic Requirements for Declaration Process Management 


1 SCOPE 


This standard provides the principles and details necessary for declarations between members of a 
supply chain. Although this 1751 standard contains only generic information regarding trading partners, 
when combined with another specific 175x Sectional standard, the resulting document set is used to 
define and maintain the declaration information. The requirements pertain to both hard copy and 
electronic data descriptions. This standard provides for the creation of a record between trading partners, 
and therefore the data communicated may be used to help support and demonstrate due diligence in any 
subsequent representation based upon its contents. 


1.1 Purpose 


The purpose of the standard is to establish a methodology for a product or business attribute declaration 
process between suppliers and their customers which will define the form, structure, and content of the 
declaration to such an extent that it may be conveyed electronically without the necessity of human 
intervention. The standard benefits its adherents by providing consistency, efficiency, and integrity to the 
declaration process. 


The purpose of this document is also to describe in text what the electronic data content consists of, so 
that its capabilities can be assessed, judged, and adopted by those in need of such a standardized 
approach to information exchange. 


Because organizations may choose to verify information provided under this standard, brief procedures 
are described within this standard for such verification (see section 8). 


1.2 Intent 


The intent of the 175x standard set is to establish a standard data exchange format that will facilitate, 
improve, and secure data transfer between all members of a supply chain. 


The intent of the 1751 standard is to define the generic information comprising the basis for such data 
exchange: who is requesting or making the declaration, basic identification and contact information for 
the party or parties involved, if there is a requester, then who is the recipient of the request, when is this 
happening, and similar basic information. The 1751 standard then intends to provide definition of the 
electronic data exchange format sufficient to convey mandatory and optional data contents. 


IPC-1751 is “generic” because it specifies only basic identification and communication information which 
form the basis for further specific declarations. IPC-1751 is therefore intended to be used in conjunction 
with other 175x standards as needed which may be employed similar to menu items, building on the 1751 
foundation. 


Part of the intent is also to provide mechanisms for securing the integrity of the information exchanged. 


1.3 Documentation Hierarchy 


This 1751 standard establishes the generic requirements for a declaration process used to provide 
information with respect to a specified product or products on subjects of concern arising in the course of 
conducting business. 
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Declaration specifics are defined by each standard in the IPC-175x series of standards. Each standard 
has a specific focus and shall be used, as appropriate, to describe a particular declaration process. The 
Sectional standards and their focus are: 

Version 2.0: 

IPC-1751 Generic Requirements for Declaration Process Management 

IPC-1752 Materials Declaration Management 

IPC-1756 Manufacturing Process Data Management 


Future Sectionals: 

IPC-1753 Laminate Structure Declaration Management 

IPC-1754 Printed Board Declaration Management 

IPC-1755 Electronic Assembly Declaration Management 

IPC-1756 Manufacturing Process Data Management 

IPC-1758 Declaration of Shipping, Packing and Packaging Materials 


1.4 Interpretation 


The word “shall,” the emphatic form of the verb, is used throughout this standard whenever a 
requirement is intended to express a provision that is mandatory. Deviation from a “shall” requirement 
may be considered if sufficient data is supplied to justify the exception. The words “should” and “may” 
are used to express non-mandatory provisions intended to be recommendations. “Will” is used to express 
a declaration of purpose related to the text description. To assist the reader, the word “shall” is presented 
in bold characters. 


1.5 Presentation 


All dimensions in the 175x standard series are expressed in metric units with millimeters the main form of 
dimensional expression. Inches may be shown in brackets as appropriate and are not always a direct 
conversion depending on round-off discrepancies or the required precision. Users are cautioned to 
employ a single dimensioning system and not intermix millimeters and inches. The measurement of 
volume and mass (weight) shall also be in SI units. Reference information is shown in parentheses ( ). 


2 APPLICABLE DOCUMENTS 


The following documents form a part of this standard to the extent specified herein. The revision of the 
document in effect at the time a declaration is produced shall take precedence. 


2.1 IPC Standards 


IPC-T-50 Terms and Definitions 


W3C XML: http:/Awww.w3.org/XML/ 
W3C XML Schema: http://www.w3.org/XML/Schema 
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3 REQUIREMENTS 


The following requirements are applicable to all the IPC-175x series of declaration management 
standards. In the event that a particular requirement does not apply, the alternate methodology is defined 
in the Sectional standard. 


3.1 Terms and Definitions 


The definition of all terms shall be in accordance with IPC-T-50 and the following. An asterisk (*) by the 
term indicates that it is a reproduction from IPC-T-50 and is provided to assist the reader in interpretation 
of this standard. 

3.1.1 compliance 

Demonstration of meeting a government regulation, law, or directive. 


3.1.2 due diligence 
Actions exercised and reasonable steps taken to avoid misrepresentation or committing of an offense. 


3.1.3 producer 


Any company or organization that, irrespective of the selling technique, manufactures and sells electrical 
and electronic equipment under their own brand, or resells under their own brand equipment produced by 
other suppliers, or imports/exports electrical and electronic equipment on a professional basis. 


3.1.4 product 
Any item such as substance, material, sub-part, part, sub-assembly or assembly that is the subject of a 
declaration. 


3.1.5 product object 


One or more products grouped together for the purpose of associating selected IPC-175x Sectional 
information to the grouping such that the provided information applies equally to each member of the 
grouping, thus alleviating the necessity for the supplier to provide the same information multiple times. 
See 5.2. 


3.1.6 requester 

The party initiating the 175x communication when using the request/response communication mode. The 
requester is the recipient of the supplier's response. 

3.1.7 subproduct 


An entry applied to a product object for the purpose of defining a portion of that product per the supplier’s 
bill of materials, engineering documentation, or other logical structure. Subproducts may have their own 
subproducts; the number of subproduct levels is limited by logic and not the IPC-175x schema. The 
supplier provides all subproduct information. Requesters do not enter subproducts. See 5.2.2. 


3.1.8 supplier 
The organization or company responsible for providing the goods and/or services required to produce an 
electrical or electronic product. 


3.1.9 user 


The individual, organization, company or agency responsible for the procurement of electrical/electronic 
hardware, having the authority to define the class of equipment and any variation or restriction (i.e., the 
originator/custodian of the contract detailing these requirements). 
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4 FAMILY OF STANDARDS 


This standard establishes the generic requirements for the declaration process herein defined. The 
standard becomes a mandatory part of any of the Sectional standards that are identified as part of the 
175x series. The details are substantiated through the use of UML information. The specific requirements 
for the 1751 portion of this declaration system include naming the requester if there is one, naming the 
supplier to whom the request is addressed, or who is providing the declaration if not specifically 
requested, naming the product or products to which the declaration applies, and providing relevant 
ancillary information to facilitate and validate the information exchange. 


4.1 Generic Declaration (IPC-1751) 


This document covers requester and/or supplier company information, the products covered, a selection 
for detailed Sectional data (presently 1752 and 1756), with an optional electronic signature and a 
statement addressing legal validity. Either the supplier or the requester may initiate the form. See Section 
5 for details. 


An inquiry coming from a requester to a supplier should include the requester company and contact 
information, their product number(s) and supplier's manufacturing number(s), the type of information (per 
IPC-175x Sectionals and Subsectionals) and legal commitment requested. It shall also include 
identification of the product or products for which the information is requested. 


In response, the supplier may then provide their company and contact information and the data being 
requested for the products the requester identifies. 


If a supplier is simply offering a declaration without a specific request, the supplier will enter their 
company and contact information and indicate their preferred legal commitment. The supplier will also 
then provide the detail of data pertaining to the named product or products per the provisions of IPC-175x 
Sectionals and Subsectionals that the supplier selects. 


Beta software Test 2 pubject to copyright tion and is in the public do: 


This document is a supper declaration for a product or nO respo y wih for its use by other parties, and makes no guaran e o 
reliability, or any other characteristic. We wou! id appreciate ad knowledgement if the software is a y 


See IPC Web Site for Information on IPC-1750 Series Form Type Version 


Standard http://wewew.ipc.org/IPC-175x” Request/Reply v 12.0 > [ 
Requester Information Request/Reply — 
= 3E Distribute aE are) 
Figure 4-1 Example of how the form type and Sectional choice might appear in an implementation 
(Refer to Appendix A for field descriptors) 


The form type, whether Request/Reply (if one company is requesting a declaration from a supplier) or 
Distribute (if a supplier is proactively offering a declaration), shall be chosen as shown in the example 
Figure 4-1. 


4.2 Materials Declaration Management (IPC-1752) 


The details regarding the exchange of materials declaration data are defined in IPC-1752. A UML data 
model with the corresponding XML schema is provided to facilitate the information exchange between the 
producer and the customer. 


IPC-1752 materials information is associated with the generic 1751 Sectional information by selecting 
“Materiallnfo.” When the 1752 Sectional standard is so chosen, an additional selection of one or more 
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1752 Subsectionals is thereby necessitated. See IPC-1752 for a description of the four Subsectional 
alternatives. Also see Clause 5.2 for associating 1752 information with a product object. 


4.3 Laminate Structure Declaration Management (IPC-1753) 


This standard is under consideration and is intended to become a replacement for IPC-1730. The new 
standard will use the generic standard, IPC-1751, to provide company information. 


4.4 Printed Board Declaration Management (IPC-1754) 


This standard is under consideration is intended to become a replacement for IPC-1710 in the near 
future. The new standard will use the generic standard, IPC-1751, to provide company information. 


4.5 Electronic Assembly Declaration Management (IPC-1755) 


This standard is under consideration and is intended to become a replacement for IPC-1720 in the near 
future. The new standard will use the generic standard, IPC-1751, to provide company information. 


4.6 Manufacturing Declaration Management (IPC-1756) 


The IPC-1756 standard contains manufacturing information. In version one of 175x this information was 
included in 1752, but it has been moved to the IPC-1756 Sectional and expanded. This new standard will 
use the generic standard, IPC-1751, to provide business information and the product definition to which 
the declaration applies. See paragraph 5.2 for associating 1756 information with a product object. 


5 DATA REQUIREMENTS FOR GENERIC DECLARATION 


The data requirements for the declaration process management concepts, consists of two modes of data 
exchange. The first mode is that of “Request/Reply” where a user wishes to obtain information about a 
product. The second mode is that of “Distribute” where a supplier wishes to make product information 
available to potential customers. 


5.1 Requester Information 


This information describes the company and person who are requesting a declaration. This information is 
only relevant when a request/response model is being followed using one of the Sectional standards. This 
section of the data model contains several fields that identify the company and the individual requesting a 
particular declaration. Each field is described in the following paragraphs and is shown in the example in 
Figure 5-1. 


Requester Information 
Company Name * | Contact Name * | | My supplier ID 
Request Document ID | Contact Title | 
Company Unique ID | Contact Phone * | | |_| Supplier provides Mfr Item Version & Manufacturing Site 
Unique ID Authority | Contact Email * | | 
Request Date * | Requester Comments 


Respond By Date [ca] 


Lock Request Fields | Additional Details 


Figure 5-1 Example of how a requester information section might appear in an implementation 
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5.1.1 Company Information 
5.1.1.1 Company Name 


This field identifies the legal name of the company requesting the declaration document. This field is 
mandatory. 


5.1.1.2 Company Unique ID 
These fields are used by industry to uniquely identify the requester company. For example, in the U.S. a 


Dun & Bradstreet Data Universal Numbering System (DUNS) number is a commonly used unique 
identification (ID). This field is optional. 


5.1.1.2.1 Unique Identity 


This field identifies the name or known designation of the requester company. This field is optional. 


5.1.1.2.2 Unique ID Authority 


This field identifies the organization that assigns the unique ID. In the example above, Dun & Bradstreet 
would be the authority assigning the unique ID. This field is optional. 


5.1.2 Request information 
5.1.2.1 Request Date 


This field identifies the date when a user requests a declaration document. All date fields use the XML 
date format. This field is mandatory. 


5.1.2.2 Request Document ID 
This field identifies the request to help the user and supplier reference the communication. A revision 


method should be established to identify different configurations of the same request. The methodology 
may be simply a single letter or date that establishes the appropriate linkage. This field is optional. 


5.1.2.3 Comment 


This field provides additional information to the supplier regarding the request. This field is optional. (see 
5.1.4.1.) 


5.1.2.4 Respond By Date 


This field identifies the date when the supplier is expected to respond to the request for information. This 
field is optional. 


5.1.2.5 Internal Supplier ID 


This field identifies a company’s internal designator for a supplier. It might be a name or a supplier 
identification code. This field is optional. (See also 5.1.4.2). 


5.1.2.6 Field Lock 


The field lock attribute permits the requester to lock in the company name, request date, contact 
information etc. This field is optional. 
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5.1.2.7 Supplier Check Box 


The supplier check box allows the supplier to provide the manufacturing item version and manufacturing 
site information for the request. If the check box is initiated the request becomes mandatory. The 
requester should not lock the fields if this data entry is required by the supplier. 


5.1.3 Contact Information 
5.1.3.1 Contact Name 


This field identifies the name of the person to contact with questions about the request for declaration. 
This field is mandatory. 


5.1.3.2 Contact Title 


This field identifies the title of the contact person. This field is optional. 


5.1.3.3 Comment 


This field provides additional information to the supplier regarding the requester contact information. This 
field is optional. (See also 5.1.4.1.) 


5.1.3.4 Contact Phone 


This field identifies the telephone number for the contact person. This field is mandatory and consists of 
two attributes: the first is the phone number and the second is the phone type, e.g., business, personal, 
mobile etc. There may be multiple phone listings for the requester contact. 


5.1.3.5 Contact Email 


This field identifies the email address for the contact person. This field is mandatory and consists of two 
attributes: the first is the email number and the second is the email type e.g., general office, personal, 
department etc. There may be multiple email listings for the requester contact. (See also 5.1.4.1) 


5.1.3.6 Additional Contact Info — Address 


The requester may provide a physical address as part of the requester contact information. These fields 
are optional. 


5.1.3.6.1 Internal 


Any internal routing information necessary. 


5.1.3.6.2 Street 


The street number and name. 


5.1.3.6.3 City 


The name of the city. 


5.1.3.6.4 State 


The state or province. 
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5.1.3.6.5 Country 


The country. 


5.1.3.6.6 Zip Code 


The postal code. 


5.1.3.6.7 Comment 


Additional comments related to the contact or contact information. 


5.1.4 Other Descriptions 
5.1.4.1 Requester Comments or URL for Additional Information 


This field provides additional information to the supplier, such as definitions of the authorized 
representative field in the supplier information section, submission instructions, additional contact 
information, or information relating to fields in the Sectional standards. These can be provided either 
directly or by a URL address which shows where the additional information can be obtained. If a URL is 
provided it should be of the form http://xxx.xxxx.xxx. This field is optional. 


5.1.4.2 My Supplier <Manufacturer> ID 


This field states a company's internal designator for a supplier, such as a supplier identification code. For 
data tracking purposes, requesters can provide this designator under the My Supplier <Manufacturer> ID 
field. This field is optional. 


5.1.4.3 Destination — URL or Email Address 


This field identifies the URL or email address to which the requester wishes the data be submitted. This 
field is optional. 


5.1.4.4 E business Information - Attachment 


One to many attachments may accompany the request for information that is exchanged between the 
user and the supplier. This field is optional however when initiated requires several attributes. The first of 
these is the name of the attachment since there are multiples that may be attached and the comments 
provided should reference the appropriate one. The second is the file type which defines the method that 
may be used to read the data. The final attribute is the data file itself. (See also 9.1.7) 


5.2 Product Information 


The 175x series of standard is based on the concept of products (as defined in 3.1.4 of this document). A 
product object therefore is simply an identification of a product or group of products to which Sectional 
information is associated using the IPC-175x schema. The declaration shall contain one or more product 
objects. Each product object may represent one or more products as defined in the product ID fields (see 
Figure 5-2). 
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| highlight this Product in Product Tree | 


[ Product | Homogeneous Material | Material Summary | Material Group | Query/Reply Material | Manufacturing Information | 


Unit 


- | Prod Number | Prod Name |Mfr Prod Num... Mfr Prod NamelMfr Prod versi..| __Mfr Site Effective Date Amount UOM Type Identity Authority 


T+ E 
TH 


Figure 5-2 Example of product object section as it may appear 
in an implementation, including multiple product IDs 


Products within a product object may be identified using multiple product numbers or with a single product 
number representing an entire family of products. If a single product number is used to represent a family 
of products, requester and supplier are advised to clarify the correspondence between requester product 
identification and supplier product identification to ensure that supplier information associates correctly 
with requester product numbers. 


Each product object shall require selection of specific Sectional information to be associated with it, such 
that the sectional information provided is true and correct for all members of the product object. Products 
included in each product object must therefore be chosen according to this principle. If products listed in a 
product object do not share Sectional information to be applied to them, then the product object shall be 
redefined so that only those products are included in the product object for which the Sectional 
information provided is true and correct. A new product object may be defined to address those products 
for which a different Sectional response is required. More than one IPC-175x Sectional may be 
associated with each product object. 


By selecting from the Sectionals, a requester or supplier associates the mechanisms for providing 
information specific to those Sectionals as they pertain to the product or products identified according to 
this 1751 Sectional. By selecting “MaterialsInfo,” the 1752 Sectional is related to the 1751 information. If 
MaterialsInfo is selected, a selection of IPC-1752 Subsectionals is also required. By selecting 
“Manufacturinginfo,” the 1756 Sectional information is related to the 1751 information. 


As stated above, the product object contains the identifying information and additionally contains the 
associated Sectionals, which the requester selects if in Request/Response mode or which the supplier 
chooses if in the Distribute mode. 


The following fields provide information identifying each product object of interest. 


5.2.1 Requester Product Number 


This field identifies the requester's number for each product included in the product object. In the 
request/response mode this field is mandatory. The requester is cautioned to include only those product 
numbers for which requested Sectional information will be identical. A new product object may be defined 
for other products or product families for which a different Sectional response is anticipated. The first 
product number listed in the product object definition is the primary one for database structuring purposes 
as necessary in specific implementations of the required schema. 


5.2.2 Requester Product Name 


This field identifies the name of the each product in the requester’s system corresponding to each product 
number. This field is optional. 
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5.2.3 Manufacturer’s Product Number 


This field identifies the number for each product in the supplier's (manufacturer’s) system as perceived by 
the requester. This field is mandatory. In the Distribute mode the supplier provides the Manufacturer’s 
Product Number. 


5.2.4 Manufacturer’s Product Name 


This field identifies the name for each product in the supplier's (manufacturer's) system as perceived by 
the requester. This field is optional. In the Distribute mode the supplier provides this entry for each 
product number. 


5.2.5 Manufacturer’s Product Version 


This field identifies the version of the product in the supplier's (manufacturer's) system as perceived by 
the requester. This field is optional. In the Distribute mode the supplier provides this entry for each 
product number. 


5.2.6 Manufacturing Site 


This field identifies the site at which the product is manufactured as perceived by the requester. This field 
is optional. In the Distribute mode the supplier provides this entry for each product number. 


5.2.7 Effective Date 


This field provides the date upon which the information provided in the 1751 Sectional, as well as 
accompanying information per any other 175x Sectional, became or becomes effective. This field is 
optional. If not provided, the effective date for all information provided is assumed to be the date of the 
response. 


5.2.8 Instance ID 


The Instance ID field is provided to allow either the requester or the supplier the means to further specify 
each product to which the declared information applies. That is, a requester may want to provide specific 
serial numbers of the products for which he is requesting a declaration, or a supplier may want to provide 
a SKU number, a lot code, a date code, an RFID number, etc. These would be entered in the Instance ID 
field. Instance IDs are associated with one particular product number only. The Instance ID field comes 
with a secondary field that is an optional open field to use in one-to-one correspondence with each 
Instance ID. There may be one or more Instance IDs associated with each product in a declaration. This 
field is optional. 


5.2.9 Instance ID Authority 


The Instance ID authority is the entity that issued the unique ID. It becomes mandatory only if there is an 
Instance ID. The authority may be defined as the supplier in the absence of any other assigning authority. 


5.2.10 Product Amount 


This field identifies the total amount of product mass in terms of a unit of measure and a value. This field 
is mandatory and is provided by the supplier whether in Request/Response mode or Distribute mode. 


5.2.11 Unit of Measure (UoM) 


This field identifies the unit of measure for the product mass — milligrams, grams, kilograms, parts per 
million, or mass percent. This field is mandatory. 
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5.2.12 Unit Type 


This field identifies the basis of quantification of the subject product or subproduct, the unit of product to 
which the associated mass (amount — UoM and value) applies. This field is called Unit Type to distinguish 
it from Unit of Measure. If the product is a discrete object, the Unit Type would be “Each.” If the product is 
a potentially boundless material, such as a length of wire, a sheet of laminate, or a liquid, the unit type 
would be per meter (millimeter, centimeter), per square meter (square millimeter, centimeter), or per liter, 
respectively. Volume may be based on cubic linear units or liters. The Unit Type is intended to refer to the 
variable dimension of the product, where the other dimensions are assumed to be held constant and 
implied or specified elsewhere, as in the product or subproduct identification. 


This field is mandatory. In the Distribute mode, the supplier provides this information. The default value is 
per “Each.” [Note: “Unit Type” is referred to as “Unit Volume” in the 175x Schema.] 


5.2.13 Subproduct 


A subproduct is a portion of a declared product. An example would be an integrated circuit in a printed 
circuit board assembly where the printed circuit board assembly is the primary product, or a subassembly 
in a computer where the computer is the primary product. Subproduct information shall consist of Mass, 
Unit of Measure, and Unit Type for every Subproduct Name. 


The Subproduct function is intended to allow a supplier to declare the product according to the detail of 
their assembly structure as their engineering documentation or bill of materials defines it. Subproducts 
therefore would reflect the supplier's assembly levels as the suppliers product definition dictates. The 
IPC-175x schema does not limit the levels of subproducts allowed. 


5.2.14 Number of Instances 


The number of instances or occurrences of the subproduct within the parent product or subproduct. This 
field is mandatory for every subproduct named, and the default value is 1. This field allows the supplier 
to state the quantity of each subproduct that occurs in the declared parent product or subproduct, such 
that when each subproduct quantity is multiplied by its mass and then the results for all subproducts are 
summed, the sum will theoretically equal the mass of the whole product. 


5.3 Supplier Information 


This information concerns the company and persons who are supplying a declaration document. Each 
field is described in more detail below; these are shown in the example in Figure 5-3. 


Supplier Information 
Company Name * Contact Name * [ Authorized Representative * | 
Response Document ID Contact Title Representative Title | 
Company Unique ID Contact Phone * >> _| Representative Phone * | 
Unique ID Authority [| | ContactEmail* | Representative Email * [CA] 
Response Date * [ca] Supplier Comments 


Figure 5-3 Example of Supplier Information Section 
(Refer to Appendix A for field descriptors) 
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5.3.1 Company Information 
5.3.1.1 Company Name 


This field contains the legal name of the company supplying the declaration document. This field is 
mandatory. 


5.3.1.2 Company Unique ID 


This field is used to uniquely identify the supplier. The DUNS number is an example of a unique ID. This 
field is optional. 


5.3.1.3 Company Unique ID Authority 


This field identifies the organization that assigns the unique ID. This field is mandatory if there is a 
Supplier Company Unique ID. 


5.3.2 Response Status 
5.3.2.1 Response Date 
This field identifies the date of the supplier's response to the request for information. If the Distribute 


model is being used (see Section 7 BUSINESS PROCESS), this is the date when the data provided in 
the declaration is completed. This field is mandatory. 


5.3.2.2 Response Document ID 
This field identifies the response in order to help the user and supplier reference communication. 
Establishing a revision method is recommended to identify different configurations of the same response. 


The methodology is as established by the supplier or the trading partners and may simply consist of a 
single letter or date code that establishes the appropriate linkage. This field is optional. 


5.3.3 Contact Information 
5.3.3.1 Contact Name 


This field identifies the name of the person/role contact regarding the contents of the declaration 
information. This field is mandatory. 


5.3.3.2 Title — Contact 


This field identifies the title of the contact. This field is optional. 


5.3.3.3 Phone — Contact 


This field identifies the telephone number for the contact. This field is mandatory. 


5.3.3.4 Email — Contact 


This field identifies the email address for the contact. If an email address is not available, state “not 
available” or “n/a.” A blank field may cause an error in form implementation. This field is mandatory. 
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5.3.4 Other Descriptions 
5.3.4.1 Authorized Representative 


This field identifies the person responsible for the content of the declaration. The authorized 
representative may be a different individual than the contact person. It is not correct to use the words 
“same” or similar identification to provide the name of the authorized representative. This field is 
mandatory. 


5.3.4.2 Title - Representative 


This field identifies the title of the authorized representative. This field is optional. 


5.3.4.3 Phone — Representative 


This field identifies the phone number of the authorized representative. This field is mandatory. 


5.3.4.4 Email - Representative 


This field identifies the email address of the authorized representative. If an email address is not 
available, state “not available” or “n/a”. A blank field may cause an error in form implementation. This field 
is mandatory. 


5.3.4.5 Supplier Comments or URL for Additional Information 


This field contains additional information that may be provided which may include a URL pointing to more 
information. This field is optional. 


5.4 Declaration Specifics 


In some instances the declaration requires substantiation of the details provided in accordance with IPC- 
1751 and any of the Sectional standards. Although the fields are optional, they become mandatory when 
the requester requires verification of a commitment by the responding authority. In that instance the 
following paragraphs apply. 


5.4.1 Commitment to the Data Provided in a Completed Declaration 


Versions of the declaration forms may have been created to allow requesters to specify that the provided 
information requires substantiation and/or to specify that the information is true and correct to the best of 
the knowledge and belief of the supplier at the time the form was completed. 


At the discretion of the company requesting the declaration (requester), the declaration may require 
substantiation of the details provided in accordance with IPC-1751 and any of the Sectional standards. In 
this situation, the supplier shall complete all the required fields in the document and designate an 
authorized representative of the company to sign the document to verify the commitment by the 
responding authority. Any disagreement regarding the statement terminology shall be mutually resolved 
between the two trading partners. 


5.4.2 Legal Statement 


For declarations which are published by the supplier, the supplier may provide a legal declaration which 
explains the extent to which the user may rely on the information provided in the declaration and which 
may limit liability. Requesters asking for data from a supplier may provide a similar legal statement which 
can be accepted or not accepted by the supplier. See Figure 5-4. 
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Legal Statement 


Supplier Acceptance * i+ 
Legal Declaration * Standard xj 


upplier certifies that it gathered the provided information and such information is true and correct to the best of its knowledge and belief, as of the date that Supplier completes this form. 
Supplier acknowledges that Company will rely on this certification in determining the compliance of its products. Company acknowledges that Supplier may have relied on information 

rovided by others in completing this form, and that Supplier may not have independently verified such information. However, in situations where Supplier has not independently verified 
information provided by others, Supplier agrees that, at a minimum, its suppliers have provided certifications regarding their contributions to the part(s), and those certifications are atleast as 

'omprehensive as the certification in this paragraph. If the Company and the Supplier enter into a written agreement with respect to the identified part(s), the terms and conditions of that 


¡greement, including any warranty rights and/or remedies provided as part of that agreement, will be the sole and exclusive source of the Supplier's liability 


Figure 5-4 Example of Legal Disclaimer, Supplier Acceptance and Attachment Fields 


5.4.2.1 Standard 


The standard legal statement follows: 


“Supplier certifies that it gathered the provided information and such information is true and 
correct to the best of its knowledge and belief, as of the date that Supplier completes this form. 
Supplier acknowledges that Company will rely on this certification in determining the compliance 
of its products. Company acknowledges that Supplier may have relied on information provided by 
others in completing this form, and that Supplier may not have independently verified such 
information. However, in situations where Supplier has not independently verified information 
provided by others, Supplier agrees that, at a minimum, its suppliers have provided certifications 
regarding their contributions to the part(s), and those certifications are at least as comprehensive 
as the certification in this paragraph. If the Company and the Supplier enter into a written 
agreement with respect to the identified part(s), the terms and conditions of that agreement, 
including any warranty rights and/or remedies provided as part of that agreement, will be the sole 
and exclusive source of the Supplier's liability and the Company’s remedies for issues that arise 
regarding information the Supplier provides in this form.” 


5.4.2.2 Custom 


A custom legal statement may be used if the standard statement cannot be used. In the request/response 
mode the requester will input the custom legal statement. In the Distribute mode suppliers may input a 
custom legal statement as well. 


5.4.3 Supplier Signature 


By signing and submitting a declaration, either digitally or in hard copy, the authorized representative 
signing the declaration is indicating acceptance of the legal statement as it applies to all of the data 
provided in the declaration. An XML file shall be signed with an XML signature conforming to the XML- 
Signature Syntax and Processing as defined in the W3C Recommendation (12 February 2002). This field 
is optional. 


5.5 Uncertainty Statement 


The supplier may provide information on the uncertainties associated with the data provided. This field is 
optional. 
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5.6 Attachments 


The supplier may attach any substantiating data files to the declaration that explain or characterize the 
position of the declaration descriptions. In many instances an attachment would be specifically related to 
the Sectional standard which is used in combination with the generic information. Attachments are 
optional. 


6 DATA MODEL 


A model is a simplified representation of a system that ignores extraneous details in order to concentrate 
on some particular aspect of the system; UML was chosen to represent this information system. An 
information model is an abstract view of a system that specifies and describes the information used by 
the system. The most useful information models describe constraints on information and relationships 
between information, in addition to the structure of the information. Machine readability is a desirable 
feature of an information model, which makes it much more useful for automation. 


6.1 Machine Readable Formats 
Ideally, a machine-readable information model would be programmatically converted into: 


e The grammars necessary to transport information 
e Skeletal computer code used to manipulate information 


e The Structured Query Language (SQL) statements necessary to define the structure of relational 
databases that store information 


e Database stored procedures used to ensure the validity of the data. 


6.2 Data Model for Declaration 


The data model for a generic declaration standard is not complex; however, there are many relationships 
and linkages that need to be addressed and established. Data modeling can improve the characteristics 
of any form or any programming that is developed at the requester’s site or the supplier's location. See 
Figure 6-1. 


Appendix B shows the characteristics of the UML model for the generic standard. This information will be 
continually evaluated and modified as the standard evolves and gains consensus. 
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gnature | Signature seen 


Figure 6-1 1751 Business Information Design Data Model 


6.3 Methods of Using UML 


There are three modes for using UML; one is as a sketch of the desired process, another is as a blueprint 
for developing details, and the third is a very detailed entry into the programming language. The most 
common is that of sketching out the ideas and relationship for a particular model. In many instances a 
data modeler goes through several iterations in order to satisfy the developing team's needs. 


The most important part of the modeling sequence is the development of the analytical model. See 
Appendix B for a full Declaration Analytical Model. The data model for a single product explores all the 
ramifications of the intended descriptions. Figure 6-2 shows an example of the analytical model for an 
electronic assembly. Once the analytical model is developed it can be converted to a design model as 
appropriate. The design model becomes very specific as to the intent and the method of model 
implementation. 


In the declaration management standard, there are several analytical models that shall be developed in 
order to cover the various details of the model implementation strategy. These are then used to develop 
the design model. The data model is shown in Figure 6-2. This data model describes the information 
necessary to be captured in a data instance, and may be used to develop software tools that facilitate 
data transfer. 
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Figure 6-2 Analytical Model of a Product that is Part of an Electronic Assembly 


7 BUSINESS PROCESS 


This section discusses the business interactions supported by the IPC-175x declaration process. 


7.1 Request/Response (Pull) 


Requests for information can come from customers, regulators, non-governmental organizations (NGOs), 
or the public. The request may be part of a procurement contract or request for quote/information, or may 
simply be a request for data. Any ambiguity in the request should be clarified. Specific information about 
the request may be attached to the request or may be provided on a web page which is described in the 
request. 


The company receiving the request (defined as the supplier) should then decide whether to respond to 
the request. 


The response to the request will depend on the requested transmission format described by the 
requester. The response shall follow the IPC-1751 generic standard and the appropriate Sectional 
information related to the declaration activity. The report/declaration should then be sent to the requester. 
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7.2 Distribute (Push) 


Another process of distributing the declaration information and the appropriate Sectional content is to 
publish it for distribution. This most often will be accomplished by making documents available on a 
corporate web site, or having them available internally for submission to a requester when a request is 
received. In this latter case, it will be important that the information in the requester fields be included with 
the response. These fields contain information that the requester needs to be able to systematically tie 
the response to the request. 


Under this process the format for generic information is combined with the requirements of the 
appropriate Sectional information and then published as a unique description related to a specific product 
or products. The publication shall follow the IPC-1751 generic standard and the appropriate Sectional 
information related to the declaration activity. 


8 VERIFICATION 


Verification involves ensuring that the information provided is accurate. Verification of declared 
information has a number of different aspects, described below. Since this generic standard deals with 
company information, additional requirements for verification are included in the Sectional standards. 


Each supplier or producer shall be responsible for determining the level of verification appropriate to their 
operations. 


If a requester Product Number and/or Manufacturer Product Number is not recognized by the supplier, 
this information must be resolved between the supplier and requester outside of the 1751 standard. 


8.1 Validation 


Validation of the company information contained in any declaration is straightforward and is often done 
systematically. Validation is the first step of any verification process, and involves checking that the data 
provided is of the correct type. For instance, if email addresses are provided, they should be in the correct 
form and contain an @ symbol, all dates must be in an approved date format, and names use characters 
rather than numbers, etc. At a minimum, any 175x file should be valid when compared to the IPC-175x 
XML schema. 


8.2 Confirmation 


After checking that data exchanged between trading partners is valid as described above, it is also 
important to check that the data is correct. Contact personnel, as well as their phone numbers, email and 
other information (as appropriate given the business need), should be established and kept up-to-date. 
Sometimes confirmation of information can be performed programmatically, such as comparing company 
names in the requester and supplier fields against information in the Company ID for the Manufacturer 
field, or comparing contact information provided by the supplier against supplier contact information in the 
requester's systems. 


If the requester has specific instructions for the supplier, they may be provided through a hyperlink to a 
web page or with the request as an attachment. The requester may wish to confirm that the supplier has 
followed these instructions, particularly any specific instructions concerning the role of the authorizing 
person. 
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8.3 Audit 


An additional level of verification consists of an audit of the supplier by the requester, a third party, or a 
supplier self-audit. Supplier audits are optional, although audit conditions are often described in the 
original business agreement between trading partners. The confidence level between trading partners 
largely determines the need for or frequency of audits. Because this generic standard deals with company 
information, a separate audit to verify this information will seldom be warranted. Requesters may wish to 
incorporate verification of how suppliers document this information within existing audit protocols. 


9 IMPLEMENTATION GUIDELINES 
9.1 Functional Requirements 


This section describes function requirements for any IPC-175x compliant software tools. 


9.1.1 Operating System 


Any operating system may be used. 


9.1.2 Platform 


The software platform used to generate or view a 175x XML file is unspecified and may be selected by 
the application developer; for instance, Excel, Word, Acrobat, Open Source, proprietary, or other platform 
may be used. 


9.1.3 File Upload and Export 


The software tool shall be able to import and export 175x series XML data files. The software tool should 
be able to merge multiple XML data files so that modules can be combined. For example, an XML file 
may be provided by the requester and response data provided by the supplier in request/reply mode, or 
separate 1752 and 1756 data files for the same product may be combined into a single declaration. The 
software may be a stand-alone data editing program or it may be part of a data management system. 


Optionally, should a supplier not be able to respond via XML or have software available to them to 
respond electronically, the supplier may provide the requested data in hard copy human readable form if 
acceptable to the requester. 


9.1.4 Field Locking 


Data inputs into a field must be ‘lockable’ to ensure the integrity of the data provided by both parties. The 
lock provides a flag in the XML file that shall be used by the software to determine whether certain fields 
are editable. The lock should operate so that the Requester can create an XML file with data they do not 
want changed, and then lock only those fields. Similarly, the Supplier should be able to lock their provided 
data to ensure its integrity. 


9.1.5 Electronic Signature 


An electronic signature shall be provided as a user option for validating the source of the information and 
to lock the electronic file from tampering. The software shall support the application and validation of 
XML Signature, as defined by the W3 Organization (http:/Awww.w3.org/TR/xmldsig-core/). 
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9.1.6 Schema Validation 

Validation involves ensuring that the data provided are of the correct type. This is done by using an XML 
parser to compare the XML file being validated against the XML schema. Requesters are encouraged to 
systematically validate data where possible to reduce the required verification effort. This can be 
accomplished through drop-down menus, click-boxes, radio buttons and logic which ensure that names 
are all characters, weights are numeric, etc. It is recommended that supporting tools provide data 
validation when an XML instance is created. Systems receiving materials data can also be set up to 
validate incoming data. 


9.1.7 Data Attachments 


Users shall be able to attach additional data files, such as laboratory test reports. The data will be 
included in the XML file. 


9.2 Additional Functionality 


This section describes additional suggested functionality for IPC-175x software. 


9.2.1 Data Validation 


It may be desirable to perform additional validation beyond schema validation. For example, substance 
weights could be summed and compared to the product weight. 


9.2.2 Additional Information Via Hyperlink 


Requesters or responders may wish to provide a hyperlink to additional information such as additional 
instructions for form completion, product information, etc. 


9.2.3 Submit by E-mail 


This option would permit suppliers to submit completed declarations via email. 


9.2.4 B2B Gateway 


This option would allow companies to establish direct business to business data exchange. 


9.2.5 Excel Data Import 


This option would allow an excel data file to be mapped to the XML schema. 


9.2.6 Contact Information Duplication 


In this option, where the same personnel data is used to complete multiple contact fields, it may be 
desirable to allow a simple button to duplicate or repeat contact information. 


9.3 Presentation Output 


The following information outlines the general system features requirements for a printable, human 
readable output of the IPC-1752 module within the 175x series. For each module there is a mapping 
between the XML Schema attribute to the printable title of the attribute’s Presentation field. 
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A report shall consist of a 1751 module section and any other selected modules. 


Presentation Fields: 


The printable output shall adhere to the rules of the XML Schema and the field Title information provided 
in the Attribute's Map. 


9.3.1 1751 Rules to Extend Schema Constraints 

Rule 1: If data is sent from a Requester to the Supplier in the Request/Reply mode, then the requester 
business information must be provided. If <BusinessInfo mode="Request/Reply"> then a <Request> 
within <BusinessInfo> is required. 

Rule 2: If data is sent directly from the Supplier in the Distribute mode, then the Requester information 
shall not exist. If <BusinessInfo mode=”Distribute”> then a <Request> within <BusinessInfo> shall not 
exist. 

Rule 3: The mass of a product shall only be in the unit of measure (UoM) of milligram, gram, or kilogram. 


Rule 4: A product shall not contain a numberOfInstances attribute (product quantity by definition is one 
only), where a subproduct may have a numberOflnstances attribute. The default value is 1. 


Rule 5: A <Product> element shall not contain a numberOfInstances attribute. 
9.3.2 Multiple Pages 


Multiple page documents shall include a document identification number and a sequential page number 
on each page. 


21 


IPC-1751A February 2010 


Appendix A 
Generic Presentation Description 


The following is an illustration that shows an example of a PDF form which relates to general company 
information. The graphic shows both the company information for the requester and the company information for 
the supplier. 


These fields will be modified to reflect the needs of IPC-1752, IPC-1753, IPC-1754, and so forth as they are 
developed. The data fields will be consistent with the needs of those standards and each will have their unique 
descriptions appended to the requester and supplier information fields. 


Requester Information 
Company Name * | Contact Name * My supplier ID 
Request Document ID | Contact Title úl | 
Company Unique ID | Contact Phone * [ Supplier provides Mfr Item Version & Manufacturing Site 
Unique ID Authority | Contact Email * 
Request Date * | Requester Comments 
Respond By Date | Im] 


Lock Request Fields | Additional Details 


Figure A-1 Example of how a Requester Information Section might appear in an Implementation 


Table A-1 Field Attributes of Requester Information Section 


Add’! Information 
Element for Solution 
Xsd element attribute Display Field Name M/O* Providers 


[Request — | Businessinfo [Date ~~ Request Dale 


Supplier provides Mfr. Item 
Request BusinessInfo | supplierCheckbox | Version and Manufacturing 
Site 


Peed 
rana | 


checkbox 


checkbox or button 


*M=Mandatory; O=Optional 


Additional 
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highlight this Product in Product Tree 


l Product Homogeneous Material j Material Summary V Material Group ] “QueryReply Material ] Manufacturing Information Ui 
— ni 


[+] -| Prod Number] Prod Name [Mfr Prod Num..|Mfr Prod NamelMfr Prod Versi..| Mfr Site Effective Date Amount UOM Type Identity Authority 
EE | | | 
[+ | | 
EL | 
Comment 


Figure A-2 Example of Product Information Section as it may appear in an Implementation 


Table A-2 Field Attributes of Product Information Section 


Add’! Information 
for Solution 
Xsd element Element attribute Display Field Name M/O* Providers 


| ProductiD | Product |requesteritemMame | RequesteritemName [O | ProductiD section | 
| ProductiD | Product | requesterltemMumber | Requester item Number_| O | ProductiD section 

| ProductiD | Product |effeciveDate  |EffectiwveDate [o | ProductD section 

| ProductiD | Product | itemName | Mfr item Name |o | ProductiD section 
ProductID section 
| ProductiD | Product | manufacturingSite | mfr Site [O | ProductiD section 
| ProductiD | Product | version | Version fo | Producti section 
| Product | MainDeclaration_| unitType  [Unittype  [m | 


MainDeclaration 


ProductID 
ProductiD ProductID section 


*M=Mandatory; O=Optional 


ProductID section 


Supplier Information 
Company Name * [ ContactName* | Authorized Representative * 
Response Document ID | Contact Title Representative Title 
Company Unique ID | Contact Phone* | [>> _ JRepresentative Phone * 
Unique ID Authority | Contact Email * Representative Email * 
Response Date * [ (ca Supplier Comments | ] 


Figure A-3 Example of Supplier Information Section 
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Table A-3 Field Attributes of Supplier Information Section 


Xsd element attribute Display Field Name M/O* Solution Providers 

| Response |Businessinfo | docID | Response Documentio. | o | _____kk | 
| Response |Businessinfo | date |ResponseDate [| mM [| ___________ | 
| Response | Businessinfo | Comment | Supplier Comments | o | | 
| UniqueID | Company | identity  |CompanyUmiqueio | o | | 
| UnigueiD | Company | authority | Unique iD Authority | o [| = | 
moo 

O 

EAS 

O 


Contact Contact Name M 
Contact Contact Title o 
Phone Contact Phone 


Email | Contact | Address | ContactEmai | m| 

SurfaceAddress | Contact |intemal |Imtemal__| O | Additional Contact into | 
SurfaceAddress | Contact [street [stet | 0 | Additional Contact Info 
SurfaceAddress_ | Contact [oy [cy | o [Additional Contactinfo | 
SurfaceAddress | Contact | stateProvince | State | O | additional Contact into | 
SurfaceAddress_ | Contact | country | Country | O | Additional Contact info | 


SurfaceAddress postalCode Zip Code Additional Contact Info 
Authorized Representative 
Phone Contact number Representative Phone M section 


Alternateltem Supplier Comments | o | __________ | 
Company Company Name apo.» | 
Authorizer Contact Name Authorizer Info section 


Authorized Representative 
Email Contact address Representative Email section 
Authorizer Contact Title 


Additional Authorizer Info 


a PU [A IP 

Authorizer Response Name Representative 
SurfaceAddress | Authorizer__ | internal | mtem | O | 

SurfaceAddress | Authorizer [street [street | 0 | Additional Authorizer Info 
SurfaceAddress | Authorizer [city |city | o | Additional Authorizer Info 
SurfaceAddress | Authorizer | stateProvince | State | O | Additional Authorizer Info 
SurfaceAddress | Authorizer__ | country | Country | O | Additional Authorizer Info | 
SurfaceAddress | Authorizer__ | postalCode | ZipCode | O | additional Authorizer Info _| 
Authorizer Representative Title oloo E] 


*M=Mandatory; O=Optional 
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Legal Statement 


Supplier Acceptance * E 


Legal Declaration * [Standard [w] 


Supplier certifies that it gathered the provided information and such information is true and correct to the best of its knowledge and belief, as of the date that Supplier completes this form 
Supplier acknowledges that Company will rely on this certification in determining the compliance of its products. Company acknowledges that Supplier may have relied on information 
rovided by others in completing this form, and that Supplier may not have independently verified such information. However, in situations where Supplier has not independently verified 
information provided by others, Supplier agrees that, at a minimum, its suppliers have provided certifications regarding their contributions to the part(s), and those certifications are at least as 
comprehensive as the certification in this paragraph. If the Company and the Supplier enter into a written agreement with respect to the identified part(s), the terms and conditions of that 


greement, including any warranty rights and/or remedies provided as part of that agreement, will be the sole and exclusive source of the Supplier s liability 


+|- Name File Type Altach Save | 


Figure A-4 Example of Legal Disclaimer, Supplier Acceptance and Attachment Fields 


Table A-4 Field Attributes of Supplier Acceptance and Attachment Section 


Add’! 
Information for 
Solution 
Xsd element Element attribute Display Field Name Providers 


| Declaration | Supplier Acceptance 
an fa 


*M=Mandatory; O=Optional 


Table A-5 Example of Form Type, Version, Sectional/Subsectional Field Names 


Add’! 
Information for 
Solution 
Xsd element Element attribute Display Field Name Providers 


MainDeclaration Ps version Version | M | 
Sectional Include name Sectionals pmp] | 
Subsectional Sectional name SubSectionals Jo | 


*M=Mandatory; O=Optional 
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Appendix B 
Declaration Analytical Model 


The following illustration is an example of a declaration analytical model intended to represent any of the IPC- 
175X family of standards. It consists of various elements and attributes necessary for trading partner information 
exchange. 


cd Data Model vA 


l PostalAddress >| Address 
Role.roleName could be Billing, 
Shipping, PhysicalLocation, 
VicePresidentOfQuality, etc. 


-  mailStop: String - comment: String 
- street: String 

- city: String 

- stateOrProvence: String 
- country: String 


eto Oud Role > PC Suits «interface» 
+reportsTo 0.. 
- roleName: String s RolePlayer 
5 5 5 
4,4 t ! f 
1 i 1 
i 1 1 
pu i ! f protocol:String 
- type: String | +team 
- date: Date T e Person >>] Contact 
E iets i = 
Sery i - title: String 
i -  firstName: Strin 
Audit.type could be A Ñ 0..* t EN apt g A 
Safety, Quality i - lastName: Se protocol could be Voice, 
i 3 -  publicKey: Stri 
Financial, etc. i BUDIERE YS OIG) Fax, telex, http, ftp, etc. 
1 
ñ k 1 
Audit.org could be ExternalAudit InternalAudit ! 
i 
ee ete - duration: int -- rat Criterion 
rl cH - remarks: String i ce — = 
IREE lab - specifications: String ! E a String 
helena. 5 2 Teh Se i O OrgComposition.reason 
Waiver, etc. : i could be Geographic, 
, etc. 1 i x 
+performingOrg +banks 0..* ! BusinessFunction, etc. 
{ i 


Declaration Organization OrgComposition 
- date: Date description: String - reason: String 
- established: Date 
- comments: String 
capabilityCategory:String 0..* “Su 
` 
H SubOrg 
1 
i - roleName: String 
Personnel Capability UnionContract 
- categoryName: String - description: String - expires: Date 
- numberOfEmployees: int - capacity: String SubOrg.roleName corresponds to 
- capacityPercent: int OrgCompositon.reason. Examples are 
- comments: String North/East/South/West (for 


reason=Geographic), and 
Sales/Engineering/Manufacturing (for 
reason=BusinessFunction). 


Personnel.categoryName could be 
QualityEngineers, IntemalAuditors, 


Engineering, Permanent, Contract, capabilityCategory could be 
Union, NonUnion, etc. ProductT ype, Process, Testing, 
ProductComplexity, ProductVolume, yo" (ordered) Vooo 
V QualityDevelopment, Services Orgld 
Financials 9 
- - year. Date - legalName: String 
- category: String bY alea int - DUNSNumber: String 
- description: String - —eamings: int -  tradingSymbol: String 
- TaxpayeridNumber: String 


Equipment Building BuildingSystem 


- quantity: int 

- limits: String 

-  calibrationFrequency: Time 
- accuracy: String 


squareFeet: int 
construction: String 
dateCommissioned: Date 


percentCoverage: int 
type: String 


- remarks: String 

- ids: String i Building.category could BuildingSystem.type could 
- manufacturer: String be Office, Manufacturing, be PowerConditioning, 

- mfgModel: String Storage, etc. Heating, SprinKers, etc. 


Equipment.category could be 
AdhesiveApplication.Stencil, 
AdhesiveApplication.Screen, 
etc. 
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Appendix C 
Previous Versions of IPC-175X 


Versions 1.0 and 1.2: 

IPC-1751 Generic Requirements for Declaration Process Management 

IPC-1752 Sectional Requirements for Material Declaration Management 

IPC-1752-1 Material and Substance Declaration Description Form — Class 1, 2, 3, and 4 
IPC-1752-2 Material and Substance Declaration Description Form — Class 1, 2, 5 and 6 
IPC-1752-3 Material and Substance Declaration Description Users Guide 
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Appendix D 
175X XML Schema 


<?xml version="1.0" encoding="UTF-8"?> 


February 2010 


<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
xmlns="http://webstds.ipc.org/175x/2.0" targetNamespace="http://webstds.ipc.org/175x/2.0" elementFormDefault="qualified"> 


<xsd:element name="MainDeclaration" type="MainDeclaration"/> 
<xsd:complexType name="MainDeclaration"> 
<xsd:sequence> 
<xsd:element name="BusinessInfo" type="BusinessInfo"/> 
<xsd:element name="Include" type="Include" minOccurs="0" maxOccurs="unbounded"/> 
<xsd:element name="Product" type="Product" maxOccurs="unbounded"/> 
<xsd:element name="Signature" type="Signature" minOccurs="0"/> 
</xsd:sequence> 
<xsd:attribute name 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="2.0"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
</xsd:complexType> 
<xsd:complexType name="Request"> 
<xsd:sequence> 
<xsd:element name="Contact" type="Contact" minOccurs="1" maxOccurs="1"/> 
<xsd:element name="RequestCompany" type="Company"/> 
<xsd:element name="RequestedInfoMatDec" type="RequestedInfoMatDec" minOccurs="0"/> 
</xsd:sequence> 
<xsd:attribute name="date" type="xsd:date" use 
<xsd:attribute name="docID" type="xsd:string"/> 
<xsd:attribute name="comment" type="xsd:string"/> 
<xsd:attribute name="respondByDate" type="xsd:date"/> 
<xsd:attribute name="internalSupplierID" type="xsd:string"/> 
<xsd:attribute name="fieldLock" type="xsd:boolean"/> 
<xsd:attribute name="supplierCheckbox" type="xsd:boolean" use: 
</xsd:complexType> 
<xsd:complexType name="Contact"> 
<xsd:sequence> 
<xsd:element name="Email" type="Email"/> 
<xsd:element name="SurfaceAddress" type="SurfaceAddress" minOccurs="0"/> 
<xsd:element name="Phone" type="Phone" maxOccurs="unbounded" /> 
</xsd:sequence> 
<xsd:attribute name="name" type="xsd:string" use 
<xsd:attribute name="title" type="xsd:string"/> 
<xsd:attribute name="comment" type="xsd:string"/> 
</xsd:complexType> 
<xsd:complexType name="UniqueID"> 
<xsd:sequence/> 
<xsd:attribute name="identity" type="xsd:string"/> 
<xsd:attribute name="authority" type="xsd:string"/> 
</xsd:complexType> 
<xsd:complexType name="UniquelDExtended"> 
<xsd:complexContent> 
<xsd:extension base="UniquelD"> 
<xsd:attribute name="revision"/> 
</xsd:extension> 
</xsd:complexContent> 
</xsd:complexType> 
<xsd:complexType name="ProductID"> 
<xsd:sequence> 
<xsd:element name="Amount" type="Amount" minOccurs="0"/> 
<xsd:element name="InstanceID" type="UniqueID" minOccurs="0" maxOccurs="unbounded"/> 


—" 


version'"> 


—" 


—" 


required"/> 


—" 


—" 


—" 


required"/> 


aN: —" 


required"/> 
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</xsd:sequence> 
<xsd:attribute name: 
<xsd:attribute name: 
<xsd:attribute name: 
<xsd:attribute name: 
<xsd:attribute name: 
<xsd:attribute name: 
<xsd:attribute name: 
</xsd:complexType> 
<xsd:complexType name="Product"> 
<xsd:sequence> 
<xsd:element name="ProductID" type="ProductID" maxOccurs="unbounded"/> 
<xsd:element name="MaterialInfo" type="MaterialInfo" minOccurs="0"/> 
<xsd:element name="ManufacturingInfo" type="ManufacturingInfo" minOccurs="0"/> 
<xsd:element name="SubProduct" type="Product" minOccurs="0" maxOccurs="unbounded"/> 
</xsd:sequence> 
<xsd:attribute name: 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="Each"/> 
<xsd:enumeration value="Meter"/> 
<xsd:enumeration value="m22"/> 
<xsd:enumeration value="m‘3"/> 
<xsd:enumeration value="cm"/> 
<xsd:enumeration value="cm"2"/> 
<xsd:enumeration value="cm"3"/> 
<xsd:enumeration value="Liter"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
<xsd:attribute name="comment" type="xsd:string"/> 
<xsd:attribute name="numberOfInstances" type="xsd:integer"/> 
</xsd:complexType> 
<xsd:complexType name="Substance"> 
<xsd:sequence> 
<xsd:element name="SubstanceID" type="UniqueID" minOccurs="0" maxOccurs="unbounded"/> 
<xsd:element name="Amount" type="Amount" minOccurs="0"/> 
<xsd:element name="Concentration" type="Concentration" minOccurs="0"/> 
<xsd:element name="SubstanceExemption" type="Exemption" minOccurs="0"/> 
</xsd:sequence> 
<xsd:attribute name: 
<xsd: attribute name: 
</xsd:complexType> 
<xsd:complexType name="Response"> 
<xsd:sequence> 
<xsd:element name="Authorizer" type="Contact"/> 
<xsd:element name="SupplyCompany" type="Company"/> 
<xsd:element name="Contact" type="Contact"/> 
</xsd:sequence> 
<xsd:attribute name="date" type="xsd:date" use="required"/> 
<xsd:attribute name="docID" type="xsd:string"/> 
<xsd:attribute name="fieldLock" type="xsd:boolean" use 
<xsd:attribute name=" 
</xsd:complexType> 
<xsd:complexType name="Company"> 
<xsd:sequence> 
<xsd:element name="CompanyID" type="UniqueID" minOccurs="0" maxOccurs="unbounded"/> 
</xsd:sequence> 
<xsd:attribute name: 
</xsd:complexType> 
<xsd:complexType name="Threshold"> 
<xsd:attribute name="overThreshold" type="xsd:boolean"/> 


=" —" 


itemName" type="xsd:string"/> 
itemNumber" type="xsd:string"/> 
manufacturingSite" type="xsd:string"/> 
effectiveDate" type="xsd:date"/> 

version" type="xsd:string"/> 
requesterltemName" type="xsd:string"/> 
requesterltemNumber" type="xsd:string"/> 


—” 
—" 
—” 
—" 
—" 


—" 


—" 


unitType"> 


—" 


—" 


—" 


name" type="xsd:string"/> 
comment" type="xsd:string"/> 


—" 


—" 


required"/> 


—" 


comment" type="xsd:string"/> 


=t —" —" 


name" type="xsd:string" use="required"/> 
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<xsd:attribute name="threshold" type="xsd:string"/> 
<xsd:attribute name="intentionallyAdded" type="xsd:boolean"/> 
</xsd:complexType> 
<xsd:complexType name="Declaration"> 
<xsd:attribute name="legalType"> 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="Standard"/> 
<xsd:enumeration value="Custom"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
<xsd:attribute name="supplierAcceptance" type="xsd:boolean"/> 
<xsd:attribute name="legalDef" type="xsd:string"/> 
<xsd:attribute name="uncertaintyStatement" type="xsd:string"/> 
</xsd:complexType> 
<xsd:complexType name="Amount"> 
<xsd:attribute name="UOM"> 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="mg"/> 
<xsd:enumeration value="g"/> 
<xsd:enumeration value="kg"/> 
<xsd:enumeration value="ppm"/> 
<xsd:enumeration value="massPercent"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
<xsd:attribute name 
</xsd:complexType> 
<xsd:complexType name="Concentration"> 
<xsd:attribute name="value" type="xsd:float"/> 
</xsd:complexType> 
<xsd:complexType name="HomogeneousMaterial"> 
<xsd:sequence> 
<xsd:element name="Amount" type="Amount"/> 


—" 


—" 


—" 


—" 


value" type="xsd:float"/> 
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<xsd:element name="SubstanceCategoryList" type="SubstanceCategoryList" minOccurs="0" maxOccurs="unbounded"/> 


</xsd:sequence> 
<xsd:attribute name="name" type="xsd:string"/> 
<xsd:attribute name=" 
<xsd:attribute name 
</xsd:complexType> 
<xsd:complexType name="SubstanceCategory"> 
<xsd:sequence> 
<xsd:element name="Amount" type="Amount" minOccurs="0"/> 
<xsd:element name="Substance" type="Substance" minOccurs="0" maxOccurs="unbounded"/> 
<xsd:element name="Threshold" type="Threshold" minOccurs="0"/> 
<xsd:element name="SubstanceCatExemptionList" type="ExemptionList" minOccurs="0"/> 
<xsd:element name="Concentration" type="Concentration" minOccurs="0" maxOccurs="unbounded"/> 
</xsd:sequence> 
<xsd:attribute name="name" type="xsd:string"/> 
<xsd:attribute name="comment" type="xsd:string"/> 
<xsd:attribute name="descriptionOfUse" type="xsd:string"/> 
</xsd:complexType> 
<xsd:complexType name="ExemptionList"> 
<xsd:sequence> 
<xsd:element name="ExemptionListID" type="UniqueID"/> 
<xsd:element name="Exemption" type="Exemption" maxOccurs="unbounded"/> 
</xsd:sequence> 
</xsd:complexType> 
<xsd:complexType name="Exemption"> 
<xsd:attribute name="identity" type="xsd:string"/> 


—" 


comment" type="xsd:string"/> 
materialGroupName" type="xsd:string"/> 


—" 
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<xsd:attribute name="description" type="xsd:string"/> 
</xsd:complexType> 
<xsd:complexType name="Attachment"> 
<xsd:attribute name="name" type="xsd:string"/> 
<xsd:attribute name="fileType" type="xsd:string"/> 
<xsd:attribute name="fileData" type="xsd:base64Binary"/> 
</xsd:complexType> 
<xsd:complexType name="Internal"> 
<xsd:attribute name="identity" type="xsd:string"/> 
<xsd:attribute name="source" type="xsd:string"/> 
</xsd:complexType> 
<xsd:complexType name="MaterialInfo"> 
<xsd:sequence> 
<xsd:element name="ExemptionList" type="ExemptionList" minOccurs="0"/> 
<xsd:element name="Query List" type="QueryList" minOccurs="0" maxOccurs="unbounded"/> 
<xsd:element name="MaterialGroupList" type="MaterialGroupList" minOccurs="0" maxOccurs="1"/> 
<xsd:element name="SubstanceCategoryList" type="SubstanceCategoryList" minOccurs="0" maxOccurs="unbounded"/> 
<xsd:element name="HomogeneousMaterialList" type="HomogeneousMaterialList" minOccurs="0" maxOccurs="1"/> 
</xsd:sequence> 
</xsd:complexType> 
<xsd:complexType name="BusinessInfo"> 
<xsd:sequence> 
<xsd:element name="Response" type="Response" minOccurs="0"/> 
<xsd:element name="Request" type="Request" minOccurs="0"/> 
<xsd:element name="Declaration" type="Declaration" minOccurs="0"/> 
<xsd:element name="EBusinessInfo" type="EBusinessInfo" minOccurs="0"/> 
</xsd:sequence> 
<xsd:attribute name 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="Distribute"/> 
<xsd:enumeration value="Request/Reply"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
</xsd:complexType> 
<xsd:complexType name="QueryList"> 
<xsd:sequence> 
<xsd:element name="Query" type="Query" maxOccurs="unbounded"/> 
</xsd:sequence> 
<xsd:attribute name="identity" type="xsd:string"/> 
</xsd:complexType> 
<xsd:complexType name="Query"> 
<xsd:attribute name="statement" type="xsd:string"/> 
<xsd:attribute name="response" type="xsd:boolean"/> 
</xsd:complexType> 
<xsd:complexType name="EBusinessInfo"> 
<xsd:sequence> 
<xsd:element name="Attachment" type="Attachment" minOccurs="0" maxOccurs="unbounded"/> 
</xsd:sequence> 
</xsd:complexType> 
<xsd:complexType name="ManufacturingInfo"> 
<xsd:sequence> 
<xsd:element name="Package" type="Package"/> 
</xsd:sequence> 
<xsd:attribute name 
</xsd:complexType> 
<xsd:complexType name="Package"> 
<xsd:sequence> 
<xsd:element name="Solder" type="Solder"/> 
<xsd:element name="Terminal" type="Terminal" maxOccurs="unbounded"/> 
<xsd:element name="PSLRating" type="PSLRating" maxOccurs="1" minOccurs="1"/> 


—" 


mode" use="required"> 


—" 


—" —" 


comment" type="xsd:string"/> 
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</xsd:sequence> 


<xsd:attribute name 


<xsd:simpleType> 


<xsd:restriction base 


—" 


mslRating"> 


—" 


xsd:string"> 


<xsd:enumeration value="1"/> 
<xsd:enumeration value="2"/> 
<xsd:enumeration value="2a"/> 
<xsd:enumeration value="3"/> 
<xsd:enumeration value="4"/> 
<xsd:enumeration value="5"/> 
<xsd:enumeration value="5a"/> 
<xsd:enumeration value="6"/> 
<xsd:enumeration value="NAC"/> 
</xsd:restriction> 
</xsd:simpleType> 


</xsd:attribute> 


<xsd:attribute name 


<xsd:attribute name 
<xsd:attribute name 


<xsd:simpleType> 


—” 


—" 


—" 


classificationTemp" type="xsd:float"/> 
<xsd:attribute name="maxTimeWithin5" type="xsd:float"/> 
componentRampUpRate" type="xsd:float"/> 


packageDesignator"> 


—" 


<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="AXL"/> 
<xsd:enumeration value="BGA"/> 
<xsd:enumeration value="CGA"/> 
<xsd:enumeration value="CHP"/> 
<xsd:enumeration value="DIM"/> 
<xsd:enumeration value="DIP"/> 
<xsd:enumeration value="DSO"/> 
<xsd:enumeration value="DSB"/> 
<xsd:enumeration value="LGA"/> 
<xsd:enumeration value="PGA"/> 
<xsd:enumeration value="QFF"/> 
<xsd:enumeration value="QFJ"/> 
<xsd:enumeration value="QFN"/> 
<xsd:enumeration value="QFP"/> 
<xsd:enumeration value="RAD"/> 
<xsd:enumeration value="SIM"/> 
<xsd:enumeration value="SIP"/> 
<xsd:enumeration value="SMC"/> 
<xsd:enumeration value="SMO"/> 
<xsd:enumeration value="SOF"/> 
<xsd:enumeration value="SOJ"/> 
<xsd:enumeration value="SON"/> 
<xsd:enumeration value="SOT"/> 
<xsd:enumeration value="SVP"/> 
<xsd:enumeration value="THC"/> 
<xsd:enumeration value="THO"/> 
<xsd:enumeration value="UCI"/> 
<xsd:enumeration value="WLB"/> 
<xsd:enumeration value="ZIP"/> 
<xsd:enumeration value="NAC"/> 

</xsd:restriction> 


</xsd:simpleType> 


</xsd:attribute> 

<xsd:attribute name 
<xsd:attribute name 
<xsd:attribute name 
<xsd:attribute name 


—" 
—" 
=i. 


—" 


preheatMinTemp" type="xsd:float"/> 
preheatMaxTemp" type="xsd:float"/> 


preheatDuration" type="xsd:float"/> 


componentTempSpike" type="xsd:float"/> 


<xsd:attribute name="timeAbove217" type="xsd:float"/> 


<xsd:attribute name 
</xsd:complexType> 
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componentRampDownRate" type="xsd:float"/> 
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<xsd:complexType name="Solder"> 
<xsd:attribute name="numberProcessingCycles"> 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="1"/> 
<xsd:enumeration value="2"/> 
<xsd:enumeration value="3"/> 
<xsd:enumeration value="4"/> 
<xsd:enumeration value="5"/> 
<xsd:enumeration value="6"/> 
<xsd:enumeration value="7"/> 
<xsd:enumeration value="8"/> 
<xsd:enumeration value="9"/> 
<xsd:enumeration value="10"/> 
<xsd:enumeration value="NAC"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
<xsd:attribute name 
<xsd:attribute name 
</xsd:complexType> 
<xsd:complexType name="Terminal"> 
<xsd:attribute name="shape"> 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="Bulk solder"/> 
<xsd:enumeration value="C bend"/> 
<xsd:enumeration value="Solder lug"/> 
<xsd:enumeration value="Flat"/> 
<xsd:enumeration value="Gull wing"/> 
<xsd:enumeration value="High-current cable"/> 
<xsd:enumeration value="Insulated"/> 
<xsd:enumeration value="J bend"/> 
<xsd:enumeration value="L bend"/> 
<xsd:enumeration value="No lead"/> 
<xsd:enumeration value="Pin"/> 
<xsd:enumeration value="Quick connect"/> 
<xsd:enumeration value="Wraparound"/> 
<xsd:enumeration value="S bend"/> 
<xsd:enumeration value="Through-hole"/> 
<xsd:enumeration value="J inverted"/> 
<xsd:enumeration value="Wire"/> 
<xsd:enumeration value="Screw"/> 
<xsd:enumeration value="NAC"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
<xsd:attribute name="size" type="xsd:float"/> 
<xsd:attribute name="numberOfInstances" type="xsd:integer"/> 
<xsd:attribute name="terminalBaseAlloy"> 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="Alloy 42"/> 
<xsd:enumeration value="Copper Alloy"/> 
<xsd:enumeration value="Beryllium Copper"/> 
<xsd:enumeration value="Brass"/> 
<xsd:enumeration value="Phosphor Bronze"/> 
<xsd:enumeration value="Kovar"/> 
<xsd:enumeration value="Other"/> 
<xsd:enumeration value="NAC"/> 
</xsd:restriction> 
</xsd:simpleType> 


—" 


—" 


maxWaveSolderTemp" type="xsd:float"/> 
maxTotalWaveTime" type="xsd:float"/> 


—" 


—" 


—" 
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</xsd:attribute> 
<xsd:attribute name="bulkSolderTermination"> 
<xsd:simpleType> 


<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="Sn03"/> 
<xsd:enumeration value="Sn05"/> 
<xsd:enumeration value="Sn10"/> 
<xsd:enumeration value="Sn60"/> 
<xsd:enumeration value="Sn62"/> 
<xsd:enumeration value="Sn63"/> 
<xsd:enumeration value="SAC101"/> 
<xsd:enumeration value="SAC105"/> 
<xsd:enumeration value="SAC125"/> 
<xsd:enumeration value="SAC255"/> 
<xsd:enumeration value="SAC305"/> 
<xsd:enumeration value="SAC310"/> 
<xsd:enumeration value="SAC405"/> 
<xsd:enumeration value="NAC"/> 

</xsd:restriction> 


</xsd:simpleType> 
</xsd:attribute> 
<xsd:attribute name: 

<xsd:simpleType> 


="plating"> 

<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="Gold (Au)"/> 
<xsd:enumeration value="Gold (Au) - electroplated"/> 
<xsd:enumeration value="Gold (Au) - hard"/> 
<xsd:enumeration value="Indium (In)"/> 
<xsd:enumeration value="Nickel/Gold (Ni/Au)"/> 
<xsd:enumeration value="Nickel/Gold (Ni/Au) - electrolytic"/> 
<xsd:enumeration value="Nickel/Gold (Ni/Au) - ENIG"/> 
<xsd:enumeration value="Nickel/Palladium (Ni/Pd)"/> 
<xsd:enumeration value="Nickel/Palladium/Gold (Ni/Pd/Au)"/> 
<xsd:enumeration value="Nickel/Palladium/Gold (Ni/Pd/Au) - ENEPIG"/> 
<xsd:enumeration value="Organic Solderability Preservative (OSP)"/> 
<xsd:enumeration value="Organic Solderability Preservative (OSP-HT) - high temperature"/> 
<xsd:enumeration value="Palladium (Pd)"/> 
<xsd:enumeration value="Platinum/Palladium/Silver (Pt/Pd/A g)"/> 
<xsd:enumeration value="Silver (Ag)"/> 
<xsd:enumeration value="Silver (Ag), electroplated"/> 
<xsd:enumeration value="Silver (Ag), immersion"/> 
<xsd:enumeration value="Silver (Ag), with Nickel (Ni) barrier"/> 
<xsd:enumeration value="Silver/Palladium (Ag/Pd)"/> 
<xsd:enumeration value="Silver/Palladium (Ag/Pd), Ni barrier"/> 
<xsd:enumeration value="Tin (Sn)"/> 
<xsd:enumeration value="Tin (Sn), bright"/> 
<xsd:enumeration value="Tin (Sn), bright, annealed"/> 
<xsd:enumeration value="Tin (Sn), bright, fused"/> 
<xsd:enumeration value="Tin (Sn), bright, reflowed"/> 
<xsd:enumeration value="Tin (Sn), bright, reflowed over Nickel (Ni) barrier"/> 
<xsd:enumeration value="Tin (Sn), bright, with Nickel (Ni) barrier"/> 
<xsd:enumeration value="Tin (Sn), bright, with Silver (Ag) barrier"/> 
<xsd:enumeration value="Tin (Sn), hot dipped"/> 
<xsd:enumeration value="Tin (Sn), immersion"/> 
<xsd:enumeration value="Tin (Sn), matte"/> 
<xsd:enumeration value="Tin (Sn), matte, annealed"/> 
<xsd:enumeration value="Tin (Sn), matte, fused"/> 
<xsd:enumeration value="Tin (Sn), matte, reflowed"/> 
<xsd:enumeration value="Tin (Sn), matte, reflowed over Nickel (Ni) barrier"/> 
<xsd:enumeration value="Tin (Sn), matte, with Nickel (Ni) barrier"/> 
<xsd:enumeration value="Tin (Sn), matte, with Silver (Ag) barrier"/> 
<xsd:enumeration value="Tin (Sn), reflowed"/> 
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<xsd:enumeration value="Tin (Sn), Semi-matte"/> 
<xsd:enumeration value="Tin/Bismuth (SnBi)"/> 
<xsd:enumeration value="Tin/Bismuth (SnBi) - 5% Bi"/> 
<xsd:enumeration value="Tin/Bismuth/Gold (Sn/Bi/Au)"/> 
<xsd:enumeration value="Tin/Copper (Sn/Cu)"/> 
<xsd:enumeration value="Tin/Copper (Sn/Cu), annealed"/> 
<xsd:enumeration value="Tin/Copper (Sn/Cu), HASL"/> 
<xsd:enumeration value="Tin/Copper (Sn/Cu), hot dipped"/> 
<xsd:enumeration value="Tin/Copper (Sn/Cu), matte"/> 
<xsd:enumeration value="Tin/Lead (Sn10Pb90)"/> 
<xsd:enumeration value="Tin/Lead (Sn63Pb37)"/> 
<xsd:enumeration value="Tin/Lead/Silver (Sn/Pb/Ag)"/> 
<xsd:enumeration value="Tin/Silver (Sn/Ag)"/> 
<xsd:enumeration value="Tin/Silver (Sn/Ag), hot dipped"/> 
<xsd:enumeration value="Tin/Silver (Sn/Ag), plated"/> 
<xsd:enumeration value="Tin/Silver/Bismuth (Sn/Ag/Bi)"/> 
<xsd:enumeration value="Tin/Silver/Bismuth/Copper (Sn/Ag/Bi/Cu)"/> 
<xsd:enumeration value="Tin/Silver/Copper (Sn/Ag/Cu)"/> 
<xsd:enumeration value="Tin/Silver/Copper (Sn/Ag/Cu), hot dipped"/> 
<xsd:enumeration value="Tin/Zinc (Sn/Zn)"/> 
<xsd:enumeration value="Tin/Zinc/Aluminum (Sn/Zn/Al)"/> 
<xsd:enumeration value="Tin/Zinc/Nickel (Sn/Zn/Ni)"/> 
<xsd:enumeration value="NAC"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
</xsd:complexType> 
<xsd:complexType name="PSLRating"> 
<xsd:attribute name="wave"> 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="W0"/> 
<xsd:enumeration value="W1"/> 
<xsd:enumeration value="W2"/> 
<xsd:enumeration value="W3"/> 
<xsd:enumeration value="W4"/> 
<xsd:enumeration value="W5"/> 
<xsd:enumeration value="W6"/> 
<xsd:enumeration value="W7"/> 
<xsd:enumeration value="W8"/> 
<xsd:enumeration value="W9"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
<xsd:attribute name="waveAddInfo"> 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="A"/> 
<xsd:enumeration value="C"/> 
<xsd:enumeration value="E"/> 
<xsd:enumeration value="F"/> 
<xsd:enumeration value="G"/> 
<xsd:enumeration value="H"/> 
<xsd:enumeration value="J"/> 
<xsd:enumeration value="K"/> 
<xsd:enumeration value="M"/> 
<xsd:enumeration value="N"/> 
<xsd:enumeration value="P"/> 
<xsd:enumeration value="R"/> 
<xsd:enumeration value="Y"/> 
<xsd:enumeration value="Z"/> 
</xsd:restriction> 


—" 


zM 


IPC-1751A February 2010 


</xsd:simpleType> 
</xsd:attribute> 
<xsd:attribute name: 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="R0"/> 
<xsd:enumeration value="R1"/> 
<xsd:enumeration value="R2"/> 
<xsd:enumeration value="R3"/> 
<xsd:enumeration value="R4"/> 
<xsd:enumeration value="R5"/> 
<xsd:enumeration value="R6"/> 
<xsd:enumeration value="R7"/> 
<xsd:enumeration value="R8"/> 
<xsd:enumeration value="R9"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
<xsd:attribute name="reflowAddInfo"> 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value=" A"/> 
<xsd:enumeration value="C"/> 
<xsd:enumeration value="E"/> 
<xsd:enumeration value="F"/> 
<xsd:enumeration value="G"/> 
<xsd:enumeration value="H"/> 
<xsd:enumeration value="J"/> 
<xsd:enumeration value="K"/> 
<xsd:enumeration value="M"/> 
<xsd:enumeration value="N"/> 
<xsd:enumeration value="P"/> 
<xsd:enumeration value="R"/> 
<xsd:enumeration value="Y"/> 
<xsd:enumeration value="Z"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
</xsd:complexType> 
<xsd:complexType name="Phone"> 
<xsd:attribute name=" 
<xsd:attribute name="type" type 
</xsd:complexType> 
<xsd:complexType name="Email"> 
<xsd:attribute name="address" type="xsd:string"/> 
<xsd:attribute name="type" type="xsd:string"/> 
</xsd:complexType> 
<xsd:complexType name="SurfaceAddress"> 
<xsd:attribute name="internal" type="xsd:string"/> 
<xsd:attribute name="street" type="xsd:string"/> 
<xsd:attribute name="city" type="xsd:string"/> 
<xsd:attribute name="stateProvince" type="xsd:string"/> 
<xsd:attribute name="country" type="xsd:string"/> 
<xsd:attribute name=" 
<xsd:attribute name="type" type 
</xsd:complexType> 
<xsd:complexType name="MaterialGroupList"> 
<xsd:sequence> 
<xsd:element name="MaterialGroupListID" type="UniquelD"/> 
<xsd:element name="MaterialGroup" type="MaterialGroup" maxOccurs="unbounded"/> 
</xsd:sequence> 
</xsd:complexType> 


—" 


reflow"> 


—" 


—" 


number" type="xsd:string"/> 
="xsd:string"/> 


Si 


—" 


—" 


—" 


postalCode" type="xsd:string"/> 
="xsd:string"/> 
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<xsd:complexType name="MaterialGroup"> 
<xsd:sequence> 
<xsd:element name="Amount" type="Amount" minOccurs="0"/> 
</xsd:sequence> 
<xsd:attribute name="name" type 
</xsd:complexType> 
<xsd:complexType name="SubstanceCategoryList"> 
<xsd:sequence> 
<xsd:element name="SubstanceCategoryListID" type="UniquelDExtended"/> 
<xsd:element name="SubstanceCategory" type="SubstanceCategory" minOccurs="0" maxOccurs="unbounded"/> 
</xsd:sequence> 
</xsd:complexType> 
<xsd:complexType name="HomogeneousMaterialList"> 
<xsd:sequence> 
<xsd:element name="HomogeneousMaterial" type="HomogeneousMaterial" minOccurs="0" maxOccurs="unbounded"/> 
</xsd:sequence> 
</xsd:complexType> 
<xsd:complexType name="RequestedInfoMatDec"> 
<xsd:sequence> 
<xsd:element name="SubstanceList" type="SubstanceList"/> 
</xsd:sequence> 
</xsd:complexType> 
<xsd:complexType name="SubstanceList"> 
<xsd:sequence> 
<xsd:element name="SubstanceCategory" type="SubstanceCategory" minOccurs="0" maxOccurs="unbounded"/> 
</xsd:sequence> 
</xsd:complexType> 
<xsd:complexType name="Include"> 
<xsd:sequence> 
<xsd:element name="Sectional" type="Sectional" maxOccurs="unbounded"/> 
</xsd:sequence> 
</xsd:complexType> 
<xsd:complexType name="Sectional"> 
<xsd:sequence> 
<xsd:element name="SubSectional" type="SubSectional" minOccurs="0" maxOccurs="unbounded"/> 
</xsd:sequence> 
<xsd:attribute name 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="MaterialInfo"/> 
<xsd:enumeration value="ManufacturingInfo"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
</xsd:complexType> 
<xsd:complexType name="SubSectional"> 
<xsd:sequence> 
<xsd:element name="SubSectional" type="SubSectional" minOccurs="0" maxOccurs="unbounded"/> 
</xsd:sequence> 
<xsd:attribute name 
<xsd:simpleType> 
<xsd:restriction base="xsd:string"> 
<xsd:enumeration value="A"/> 
<xsd:enumeration value="B"/> 
<xsd:enumeration value="C"/> 
<xsd:enumeration value="D"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:attribute> 
</xsd:complexType> 
</xsd:schema> 


—" 


xsd:string"/> 


—” 


name" > 


—" 


—” 


name" > 


—" 


The schema may be downloaded at http://www.ipc.org/175X. 
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